What

This adds a fetch-post subcommand to wp_rs_cli

Why

First, this is obviously a useful feature to have for the CLI

But in particular, as discussed in recent conversations with Oguz in Slack (internal ref: p1754602450419219/1754596820.179099-slack-C08CUT5NT88), this would be especially useful to integrate the CLI into some of our current AI workflows—where we might want to ask our LLM like Claude or Cursor to use the CLI to fetch a post's content and comments and do something with the data (summarize, extract particular info from comments and reformat, etc…)

How

• Adds AuthArgs struct for common parameters related to authentication needed for this subcommand but that might also be useful to any future subcommand that might require authentication
• Add a build_api_client method to build a WpApiClient from the AuthArgs and an optional page url.
  • SiteApiType::detect_from_args will use the wpcom_site (WpCom) or api_root (WpOrg) args from AuthArgs if explicitly provided
  • But can also try to derive those from the optional url parameter if wpcom_site/api_root are not provided explicitly (extract wpcom_site from the host of the url if it's a *.wordpress.com URL, use WpLoginClient.api_discovery(url) to set api_root otherwise)
• Declare a Commands::FetchPost subcommand, with its dedicated FetchPostArgs, a subset of them coming from #[command(flatten)] auth: AuthArgs
• Implement resolve_post_id to find the post_id from a post URL / slug.
  • 🗒️ I wonder if that one would make more sense to move into the wp-rs API rather than just in the CLI, as it seems it could be useful for other contexts?
  • Or maybe there is already a method in the API to do that that I (and GPT-5) missed?
  • Or maybe there's a better way to achieve this? (I'm not super familiar with the WP API, but I could imagine there may be some more idiomatic ways to do that, or maybe variants of the API calls accepting the URL or slug directly instead of the ID…?
• Implement fetch_post_and_comments (the core implementation of the Commands::FetchPosts command) to call the WpApiClient's .posts().retrieve_with_view_context() + .comments().list_with_view_context(…) + pagination
  • 🗒️ I'm imagining that the handling of pagination could be probably made more generic in the future, so that one could apply the same trick for any request that has pagination, instead of hardcoding the while loop in the fetch_post_and_comments method. I didn't want to overcomplicate and try to optimize too early though, and figured the current approach would be ok as a first iteration of the implementation before it could be made more generic later
  • Or maybe there are already some support for auto-paginate at the WpApiClient's level that I missed?

Testing

# Obtain a bearer token (going through the OAuth flow if necessary), and set it as env var
$ export WP_BEARER_TOKEN='<your-oauth-token>'

$ cargo run -- fetch-post --url <url-to-a-p2-post>

Future directions

Since this is the first of probably many future CLI subcommands that might require authentication, it'd be nice next to have a subcommand to perform the OAuth flow.

Then once we have automatic handling of OAuth flow (call /authorize, obtain the code, exchange it for a token, store the bearer token + refresh token + expiration locally for next CLI calls to reuse, auto-refresh the token on expiration…) by the CLI itself, the AuthArgs and friends will likely be adjusted accordingly so that you don't have to pass the bearer token manually.

But all that was out of scope for this spike/experiment, so for now you're just expected to obtain the bearer token on your end and provide it to the CLI, and we can refactor that part around AuthArgs later when we get to it or add more subcommands requiring it.